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REMARKS/ARGUMENTS 



The present response is intended to be fully responsive to all points of 
objection and/or rejection raised by the Examiner and is believed to place the 
application in condition for allowance. Favorable reconsideration and allowance 
of the application is respectfully requested. 

Applicants assert that the present invention is new, non-obvious and 

useful. 

Status of Claims and Support for Changes in the Claim Listing 

Claims 1-15, 17-23, 25 and 27 were pending in the application. 
Claims 1-15, 17-23, 25 and 27 were rejected. 
Claims 1, 12, 13, 21, 25 and 27 are currently amended. 
Claims 33 and 34 are new. 

Therefore claims 1-15, 17-23, 25, 27, 33 and 34 remain pending in the 
application. 

Claims 1, 12, 13, 21, 25 and 27 have been amended so as to remove the 
limitation that the digital image communication in medicine (DICOM) modality 
worklist is generated by a hospital information system (HIS) or radiology 
information system (RIS). This limitation was added to those claims in the first 
office action reply and has caused the discussion of the application to digress to 
discussing the merits of this limitation rather than concentrating on more pertinent 
aspects of the application. By removing the limitation, Applicant desires to focus 
the discussion of the application to the novelty and innovativeness of the claims, 
as they would have read had the limitation not been added. 

Claims 33 and 34 have been added. Claims 33 and 34 are based on claims 
24 and 26 respectively which were cancelled in the first office action reply to save 
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on expenses (due to the addition of new claims which have since been cancelled). 
Claims 33 and 34 also reflect changes made to claims 25 and 27 respectively in 
previous amendments. Therefore no new matter has been added. 

Claim Rejections 

In the advisory action, the Examiner rejected the arguments of the 
Applicant, stating that the combination of Cooke, Jr. et al (US 6,574,629, 
hereinafter "Cooke") and Bocionek (US 2002/0091765, hereinafter "Bocionek") 
discloses the limitations required by the claim language. 

Applicant appreciates the time and consideration provided by the 
Examiner in reviewing this application, however, respectfully traverses the 
rejection of the claims at least for the following reasons. 

Applicant respectfully submits that neither Cooke nor Bocionek, singly or 
in combination, teaches or suggests a digital image communication in medicine 
(DICOM") modality worklist which is examined so as to ensure that in a faster 
access part of storage there is available at least some data deemed likely to be 
accessed in connection to a task scheduled by the worklist, as recited in 
independent claims 1, 13, 25 and 33. Applicant also respectfully submits that 
neither Cooke nor Bocionek, singly or in combination, teaches or suggests the 
querying of a hospital information system or radiology information system and 
receiving data related to a task scheduled by a DICOM modality worklist so as to 
ensure that in a faster access part of storage there is available at least some data 
deemed likely to be accessed in connection to that scheduled task as recited in 
independent claims 12, 27 and 34. Applicant also respectfully submits that neither 
Cooke nor Bocionek, singly or in combination, teaches or suggests a worklist 
examiner configured to examine a DICOM modality worklist and determine at 
least one type of data relating to a task scheduled by the worklist which is likely to 
be accessed and a retriever configured to transfer or copy data which is of at least 
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one of said types and is available only in a slower access part of a storage to a 
faster access part of a storage, as recited in independent claim 21. 

Before Applicant refers to arguments made by the Examiner in the 
advisory action dated 10/11/2006, Applicant requests to draw the Examiner's 
attention to document CEN/TC25 1/WG4 titled Digital Imaging and 
Communications in Medicine, Supplement 10, submitted with this RCE. As stated 
in the forward to the DICOM supplement, ACR (American College of Radiology) 
and NEMA (the National Electrical Manufacturer's Association) developed the 
DICOM standard. This supplement to the DICOM standard specifies the Basic 
Worklist Management Service Class which contains the Modality Worklist SOP 
Class which supports the transfer of the Modality Worklist from the Information 
System (IS) to the Modality (as stated in the "Scope and Field of Application 
section, page iv, line 44 to page v line 2). No limitations should be read into the 
claims or the invention based on the submitted document which is provided in 
order to show the novelty, inventive step, and usefulness of the invention over the 
prior art. 

First, it should be noted that as written on the cover sheet of the submitted 
document, the final text of the supplement is dated February 1, 1996, well before 
the filing date of the current application (2003), Cooke (1998), and Bocionek 
(2001). 

Although applicant would appreciate the Examiner reading the entire 
submitted supplement, Applicant would like to direct the Examiner's attention to 
two short sections in the submitted document. 

Refer first to DICOM Modality Worklist Part 4 Addendum page 8 line 36 
to page 9, line 27: 



Z.6.1 Modality Worklist SOP Class 

Z.6.1.1 Modality Worklist SOP Class Overview 

The Modality Worklist SOP class defined within the Basic 
Worklist Management Service Class defines an 
application-level class of service which facilitates the 
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communication of information to the imaging modality 
about Scheduled Procedure Steps, and entities related to 
the Scheduled Procedure Steps. As will be detailed below, 
part of the information carried by the worklist mechanism 
is intended to be used by the imaging modality itself, but 
much of the information is intended to be presented to the 
modality operator. 

This worklist is structured according to Scheduled 
Procedure Steps. A procedure step is a unit of service in 
the context of a requested imaging procedure. 

The Modality Worklist SOP class supports the following 
requirements: 

- Verify patient (e.g. download patient demographic 
information from IS to Modality, to verify that the person 
to be examined is the intended subject). 

- Select a Procedure Step from the IS (e.g. download 
procedure step information from the IS to the 
Modality). There are two alternatives for the realization of 
this requirement, supporting different organization 
methods of the department: The Modality may obtain the 
list of Procedure Steps from the IS. Display of the list and 
selecion from the list is done at the Modality. The list is 
displayed and selection is performed on the IS. This 
implies, that the information is obtained by the Modality 
just before the Scheduled Procedure Step starts. The 
Modality Worklist SOP class supports both of the 
organization methods. 

- Select Imaging Procedure. 

- Prepare the Imaging Procedure (Step). 

- Couple DICOM images unambiguously with related 
information from the IS (e.g. patient demographics, 
procedure description, ID data structure from the IS, 
contextual IS information). 

- Capture all the attributes from the IS, that are mandatory 
to be inserted into the DICOM Image Object 

The Modality Worklist SOP Class is not intended to 
provide access to all IS information and services which 
may be of interest to a Modality operator or attending 
physician. It's primary focus is the efficient operation of 
the image acquisition equipment. DICOM SOP Classes 
such as the existing Detached Patient Management SOP 
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Class and non-DICOM Services which fall beyond the 
scope of the Modality Worklist SOP Class may be needed. 

The Modality Worklist SOP Class does not support the 
transmission of information from the Modality to the 
information system. 

It is important to note that among the requirements supported by the 
DICOM Modality Worklist SOP Class quoted above and in the remainder of the 
submitted supplement, there is no neither a hint nor an indication of providing for 
prefetching based on the DICOM modality worklist. As stated above, the DICOM 
Modality Worklist SOP Class is not intended to provide access to all IS 
information and services since its primary focus is the efficient operation of the 
image acquisition equipment. One of the useful, innovative and novel features of 
embodiments of the invention is that it provides for prefetching, when required, 
based on DICOM modality worklist information which is in any event available 
due to the DICOM standard but was never before used for prefetching. 

Please refer now to table Z.6-2 (Attributes for the Modality Worklist 
Information Model) on pages 12 through 15 of the DICOM Modality Worklist 
Part 4 Addendum. It is evident from the table that much useful information is 
included in the DICOM modality worklist in accordance with the DICOM 
standard, which can most certainly facilitate prefetching when required as 
described in embodiments of the current application (although as mentioned 
above the information was never used before for prefetching). 

Although the submitted supplement describing the DICOM modality 
worklist was available at the time of filing of Cooke and Bocionek, Cooke 
performs prefetching that is not based on a DICOM modality worklist, even 
though Cooke uses the DICOM standard in other parts of the system (see Figure 
1), and Bocionek does not discuss prefetching at all. 
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Cooke describes a smart medical storage management system where HL7 
information is transferred from the RIS (i.e. radiology information system). Only 
the transfer of HL7 information from the RIS 44 to the RIS gateway/PACS broker 
46 is illustrated in each figure depicting both RIS 44 and PACS broker/RIS 
gateway 46. For example, see Figure 1 and Figure 4 of Cooke. See also, for 
example, column 13, lines 4 to 12 of Cooke (reproduced below) where it is 
specified that PACS broker 46 communicates in HL-7 with the RIS. 

Specifically, PACS broker 46 is a stand-alone platform 
that listens to the RIS and responds to query/retrieve 
statements from the PACS core components by accessing 
appropriate data from the RIS . To this end. PACS broker 
46 is able to communicate in HL-7 ("Health Level 7) with 
the RIS and to communicate in DICOM with network 
gateway 6. Thus, the PACS broker makes patient 
demographics , schedules, study parameters and reports on 
the RIS available to the core PACS components (underline 
added). 



It is also clearly stated in Cooke that the described pre-fetching is based on 
information received from RIS 44 which as stated above is HL-7 information. See 
for example Cooke, column 18, lines 59 to 65: 

In more detail, pre-fetching involves RIS gateway 46 
receiving information concerning a scheduled event from 
RIS 44, and then transmitting that information to the 
PACS, in particular to network gateway 6 (see FIG. 1). 
The network gateway then queries the RIS, via the RIS 
gateway, requesting details concerning the scheduled 
event, (underline added) 



See also Cooke, column 3, lines 14-37, where prefetching is further 
described: 

According to another aspect, the PACS pre-fetches 
images (and/or summaries of information relating to the 
images) in response to a scheduled event. In this regard, 
"pre-fetching" refers to the process of automatically (i.e., 
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without user intervention) retrieving images (and/or 
summaries) before the scheduled event. In this aspect, the 
PACS includes at least one station capable of displaying 
the images, and a network gateway which communicates 
with the station and a remote source (e.g., a hospital 
radiology information system, or "RIS"). The network 
gateway receives information concerning the scheduled 
event from the remote source , queries the remote source 
for details on the scheduled event, receives the details 
from the remote source, and retrieves images (and/or 
summaries) from a memory on the PACS based on the 
details and one or more predetermined pre-fetching rules. 
By effecting pre-fetching in this manner, the invention 
further reduces the amount of time required to review 
images. That is, because the images and/or summaries 
have been pre-fetched, they will be ready and waiting for 
the reviewer (e.g., a physician) at the time of the exam. 
With regard to the summaries, retrieval of the summaries 
only is a significant advantage, since it eliminates the 
need to retrieve an image when only its summary is 
needed, (underline added) 

This quote illustrates a pushing of information to the network gateway, 
whereas with the DICOM modality worklist there is no pushing of information, 
further proof that Cooke does not base prefetching on the DICOM modality 
worklist. See for example the submitted supplement page v, lines 12-16 where it 
is stated how information is obtained: "This supplement defines a service for 
communicating such worklists. The following are characteristics for this service 
class: - The worklist has to be queried by the application entity... "(under line 
added) 

See also table 1 in column 6 of Cooke where the PACS core components 
are described. The network gateway's role is described as: 



Performs DICOM validation and print ("NWG") services, 
network compression, radiology information system 
("RIS") validation, AGFA ® PACS Interface Protocol 
("APIP") translation, and workflow automation, including 
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routing, pre-fetching of prior relevant patient images, and 
generation of user-defined demographic overlays. 



Note that the term "DICOM" is used to describe the type of validation and 
print services in this quote from Cooke. However the DICOM standard is omitted 
when describing prefetching in this quote from Cooke. 

It is therefore evident that although Cooke uses the DICOM standard in 
other parts of the system, Cooke's prefetching is not based on a DICOM modality 
worklist, even though the submitted supplement describing the DICOM modality 
worklist was a final text well before the time of the filing of the Cooke 
application. Since Cooke chose to use the DICOM standard for other parts of his 
system (see for example figure 1) but to not for prefetching, Cooke in fact teaches 
away from using the DICOM modality worklist for prefetching. 

Applicant also respectfully reiterates what was previously submitted in 
replies to previous office actions, that the term "worklist" as used by Cooke not 
only is not a DICOM modality worklist but docs not even serve the same function 
as the DICOM modality worklist of the current invention. For example, Cooke 
talks about prefetching relevant studies to a reviewing station in column 1 8, lines 
55-59: 

The present invention includes the ability to route relevant 
prior studies to a reviewing station in contemplation of a 
scheduled event, such as a patient examination or the like. 
This process is called pre-fetching , and is effected by code 
executing on the network gateway, (underline added) 

Note that Cooke in column 11, lines 53 to 54 specifically equates the 
worklist with the studies: 



The worklist comprises the study, or group of studies, that 
the user selects from the main study list. 
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Therefore in contrast to the current invention where the DICOM modality 
worklist feature for example ensures that data deemed likely to be accessed in 
connection to a task scheduled by the worklist is available in a faster access part 
of storage or enables the copying/transferring of such data to a faster access part 
of storage, in Cooke it is the relevant worklists which are prefetched. This 
distinction is proof that not only is the worklist described by Cooke not a DICOM 
modality worklist but moreover the worklist in Cooke does not even remotely 
serve the same function as worklist of the invention described in the current 
application. To further hone the point, there is neither a hint nor an indication that 
in Cooke a worklist is examined or that data related to a worklist is received so as 
to ensure that data relating to a task scheduled by the worklist and likely to be 
accessed is available in a faster access part of storage or so that such data can be 
copied/transferred to a faster access part of storage. 

In Bocionek, the only time a worklist is mentioned is in the following 



In addition to these "administrative activities", the RIS 
often also acts as workflow driver in radiology in order, 
for example, to send request data in the form of a DICOM 
worklist entry to a modality such as a CT, MR or X-ray 
device at which the examination is to take place. Given 
current systems, the examination data, for example, a 
number of images, series and radiation protection data 
such as tube voltage (kV), mAs product (mAs), time (s), 
energy dose (Gy), etc., must be manually read by a worker 
and transmitted into the RIS for the required transfer of the 
examination data from the modality into the RIS for 
documentation and billing, a considerable outlay and 
additional sources of error occurs as a result. 



It is evident from this quote that in Bocionek the usage of the DICOM 
modality worklist is in accordance with the submitted supplement 10 to the 
DICOM standard discussed above. Certainly there is neither a hint nor an 



quote: 
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indication in Bocionek that the mentioned DICOM worklist is examined or that 
data related to the worklist is received so as to ensure that data relating to a task 
scheduled by the worklist and likely to be accessed is available in a faster access 
part of storage or so that such data can be copied/transferred to a faster access part 
of storage. The remainder of Bocionek mainly deals with electronic mail. 

Applicant would like to also directly address the remarks of the Examiner 
in the advisoiy action dated 10/11/2006. The Examiner took the position that 
Applicant had argued that the combination of Cooke and Bocionek does not 
disclose "examining a Digital Image Communications in Medicine (DICOM) 
modality worklist, generated by a hospital information system (HIS) or radiology 
information system (RIS) which schedules at least one modality to perform at 
least one task". Applicant has removed the clause relating to generation to make 
clear that Applicant does not believe that the merits of the invention rely on the 
generation of the DICOM modality worklist. Applicant also agrees with the 
Examiner that having a DICOM modality worklist which schedules tasks for 
modalities is well known, as evidenced by the standard supplement currently 
submitted. Applicant however takes the position that because the DICOM 
modality worklist is well known due to its being a standard, there is an 
enhancement of the usefulness of the claimed inventions. 

In the second point of argument, the Examiner states that the combination 
of Cooke and Bocionek discloses "ensuring that in the faster access part there is 
available at least some data which based on at least one predetermined rule is 
deemed likely to be accessed in connection to said at least one task to be 
performed by said at least one modality scheduled by said worklist". Applicant 
respectfully disagrees. As discussed above in more detail, Bocionek's usage of the 
DICOM modality worklist is entirely conventional as per the supplement 
currently submitted and there is certainly no mention of prefetching. Moreover, 
Cooke chose to use the DICOM standard for other parts of his system (see figure 
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1) but not for prefetching, thereby teaching away from using the DICOM 
modality worklist for prefetching. 

Based on the above, applicant respectfully submits that Applicant 
respectfully submits that neither Cooke nor Bocionek, singly or in combination, 
teach or suggest independent claims 1, 12, 13, 21, 25, 27, 33 and 34 and that 
therefore independent claim 1, 12, 13, 21, 25, 27, 33 and 34 are allowable. 

Dependent claims 2-11, 14-15 and 17-23, which depend directly or 
indirectly from the independent claims therefore include the limitations of the 
independent claims. Applicant therefore respectfully asserts that the dependent 
claims are also allowable. 

Claims 8-10 were rejected under 35 U.S.C 103(a) as being unpatentable 
over Cooke, Jr. et al (US 6,574,629) in view of Bocionek (US 2002/0091765) as 
applied to claim 1 above, and further in view of Sechrest et al (US 6,910,106). 
Applicant respectfully asserts that as independent claim 1 is allowable, dependent 
claims 8-10 which depend directly or indirectly on claim 1 are also allowable. 

Applicants believe the remarks presented hereinabove to be fully 
responsive to all of the grounds of rejection raised by the Examiner. In view of 
these remarks, Applicants respectfully submit that the specification and all of the 
claims in the present application are in order for allowance. Notice to this effect is 
hereby requested. 

Please charge any fees associated with this paper to deposit account No. 



09-0468. 



Respectfully submitted, 



By: /Stephen C. Kaufman/ 



Stephen C. Kaufman 
Reg. No. 29,551 
Phone No. (914) 945-3197 



Date: December 4, 2006 
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